<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta http-equiv="X-UA-Compatible" content="IE=edge">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Document</title>
</head>
<body>
  <h2>一、Options Api</h2>
  <div>Options API，即大家常说的选项API，即以vue为后缀的文件，通过定义methods，computed，watch，data等属性与方法，共同处理页面逻辑</div>
  <br>
  <div>缺点：当组件变得复杂，导致对应属性的列表也会增长，这可能会导致组件难以阅读和理解</div>
  <h2>二、Composition Api</h2>
  <div>在 Vue3 Composition API 中，组件根据逻辑功能来组织的，一个功能所定义的所有 API 会放在一起（更加的高内聚，低耦合）,即使项目很大，功能很多，我们都能快速的定位到这个功能所用到的所有 API</div>
  <br>
  <h2>三、对比</h2>
  <h3>逻辑组织</h3>
  <h4>Options API</h4>
  <div>选项的分离掩盖了潜在的逻辑问题。此外，在处理单个逻辑关注点时，我们必须不断地“跳转”相关代码的选项块</div>
  <h4>Compostion API</h4>
  <div>而Compositon API正是解决上述问题，将某个逻辑关注点相关的代码全都放在一个函数里，这样当需要修改一个功能时，就不再需要在文件中跳来跳去  </div>
  <h3>逻辑复用</h3>
  <div>在Vue2中，我们是用过mixin去复用相同的逻辑</div>
  <br>
  <div>使用单个mixin似乎问题不大，但是当我们一个组件混入大量不同的 mixins 的时候</div>
  <br>
  <div>会存在两个非常明显的问题：</div>
  <ul>
    <li>命名冲突</li>
    <li>数据来源不清晰</li>
  </ul>
  <script>
    // 下面举个例子，我们会另起一个mixin.js文件
    export const MoveMixin = {
      data() {
        return {
          x: 0,
          y: 0,
        };
      },

      methods: {
        handleKeyup(e) {
          console.log(e.code);
          // 上下左右 x y
          switch (e.code) {
            case "ArrowUp":
              this.y--;
              break;
            case "ArrowDown":
              this.y++;
              break;
            case "ArrowLeft":
              this.x--;
              break;
            case "ArrowRight":
              this.x++;
              break;
          }
        },
      },

      mounted() {
        window.addEventListener("keyup", this.handleKeyup);
      },

      unmounted() {
        window.removeEventListener("keyup", this.handleKeyup);
      },
      };
  </script>
  <script>
    // 然后在组件中使用
    import mousePositionMixin from './mouse'
    export default {
      mixins: [mousePositionMixin]
      // mixins: [mousePositionMixin, fooMixin, barMixin, otherMixin]
    }
  </script>
  
  <script>
    // 现在通过Compositon API这种方式改写上面的代码
    import { onMounted, onUnmounted, reactive } from "vue";
    export function useMove() {
      const position = reactive({
        x: 0,
        y: 0,
      });

      const handleKeyup = (e) => {
        console.log(e.code);
        // 上下左右 x y
        switch (e.code) {
          case "ArrowUp":
            // y.value--;
            position.y--;
            break;
          case "ArrowDown":
            // y.value++;
            position.y++;
            break;
          case "ArrowLeft":
            // x.value--;
            position.x--;
            break;
          case "ArrowRight":
            // x.value++;
            position.x++;
            break;
        }
      };

      onMounted(() => {
        window.addEventListener("keyup", handleKeyup);
      });

      onUnmounted(() => {
        window.removeEventListener("keyup", handleKeyup);
      });

      return { position };
    }
  </script>
  <script>
    // 在组件中使用
    // import { useMove } from "./useMove";
    // import { toRefs } from "vue";
    // export default {
    //   setup() {
    //     const { position } = useMove();
    //     const { x, y } = toRefs(position);
    //     return {
    //       x,
    //       y,
    //     };

    //   },
    // }
  </script>
  <br>
  <div>可以看到，整个数据来源清晰了，即使去编写更多的 hook 函数，也不会出现命名冲突的问题</div>
  <h2>小结</h2>
  <ul>
    <li>在逻辑组织和逻辑复用方面，Composition API是优于Options API</li>
    <li>因为Composition API几乎是函数，会有更好的类型推断。</li>
    <li>Composition API对 tree-shaking 友好，代码也更容易压缩</li>
    <li>Composition API中见不到this的使用，减少了this指向不明的情况</li>
    <li>如果是小型组件，可以继续使用Options API，也是十分友好的</li>
  </ul>
</body>
</html>